Review: Release prep 1.0.0

Overall this is a tight, well-scoped release-prep PR. The rationale is clearly documented and the changes are minimal. A few notes below.

✅ What's correct

Info.plist version bumps — CFBundleShortVersionString 1.0.0-beta3 → 1.0.0 and CFBundleVersion 3 → 4 are both correct. Sparkle compares CFBundleVersion (the integer build number) when deciding whether to offer an update, so 4 > 3 ensures existing beta3 users are prompted. Storing it as <string> in the plist is standard.

appcast.xml cleanup — The removed entry had sparkle:version=1, so 1 < 3 (beta3's build number) and it was permanently un-offerable. The enclosure URL pointed at a non-existent release asset. Removing it is correct; leaving it alongside the real 1.0.0 entry would have created a confusing duplicate with a broken download URL.

Pre-release detection logic — [[ "$VERSION" == *-* ]] correctly identifies semver pre-release strings (anything with a hyphen). Stable X.Y.Z versions fall through cleanly.

set -u safety — Explicitly initializing PRERELEASE_FLAG="" before the conditional covers the case where the script runs with set -u. The ${PRERELEASE_FLAG:+...} form then safely handles the empty-string case without passing a blank argument to gh.

CHANGELOG — Cutting the 1.0.0 section from Unreleased looks correct. Dropping the internal CI notes ("CI enforces coverage non-regression…") and the release-blocker issue reference is appropriate for a user-facing changelog. The Security section leading the 1.0.0 entry is a good call given the cmd feature removal is a meaningful safety property.

Minor findings

release.sh: slight redundancy in the flag expansion

PRERELEASE_FLAG=""
if [[ "$VERSION" == *-* ]]; then
    PRERELEASE_FLAG="--prerelease"
fi
...
${PRERELEASE_FLAG:+"$PRERELEASE_FLAG"} \

Because the flag string is a constant (--prerelease), the variable reference in the expansion is redundant — the value of PRERELEASE_FLAG is already identical to the string you'd want to substitute. A slightly cleaner form is:

${PRERELEASE_FLAG:+--prerelease} \

No functional difference; just removes one indirection. Not a blocker.

--notes URL is self-referential

--notes "See [release notes](https://github.com/malpern/KeyPath/releases/tag/v${VERSION}) for details."

The body of the GitHub Release links back to the same release page. This is pre-existing behavior (not introduced here), but worth fixing at some point — e.g., linking to the CHANGELOG or a help guide instead.

CHANGELOG missing comparison links

Keep a Changelog convention expects a footer link block like:

[1.0.0]: https://github.com/malpern/KeyPath/compare/v0.0.0-internal...v1.0.0
[0.0.0-internal]: https://github.com/malpern/KeyPath/commits/v0.0.0-internal

These are optional if the repo doesn't use them today, but worth adding at some point for navigability. Not blocking for 1.0.0.

[Unreleased] section — After this PR, the [Unreleased] section is empty. That's correct per Keep a Changelog conventions (empty is the right state between releases), just confirming it's intentional.

No concerns on

• Helper plist staying at 1.1.0/2 — the reasoning (avoid re-approval prompt on auto-update) is sound, and it's explicitly noted in the PR description.
• No Swift source changes means the Swift review gate and test suite are not relevant here.
• The VERSION == *-* check won't false-positive on realistic version strings in this project.

Verdict: Ready to merge. The minor notes above are all post-1.0 cleanup candidates, nothing blocking.